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Purpose 


Introduce  an  elicitation  and  diagnostic  technique — influence  maps 
(IMs) —  and  a  formal  reasoning  framework,  and  show  how  they  provide 
useful  insights  into  cross-program  and  inter-organizational 
programmatic  conflicts  in  systems  of  systems. 
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Introduction 
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•  The  problem-elaborated 

•  Brief  introduction  to  modal  logics 
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•  System-of-systems  programmatics 

“Laws”  of  programmatics 
Reasoning  Framework 

•  Extremely  simple  example 

Conclusions 
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The  Problem 


Two  PMs  (“B”  and  “C”),  reporting  to  a  PEO  (“A”) 


•  Each  PMO  has  one  development  contractor  (“B/’  and  “C^” 
respectively) 

•  There  is  a  giver-receiver  relationship  between  “B”  and  “C” 

•  Each  PMO  has  its  own  requirements,  users,  funding,  etc. 

The  interactions  of  the  systems  being  developed/acquired 
by  PMOs  “B”  and  “C”  result  in  the  emergence  of  a  system  of 
systems  (“SoSBC”) 

•  In  the  DoD  systems  engineering  guide  for  SoS,  this  is 
an  “acknowledged”  SoS 


SoS 


BC 
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The  Problem  2 


System  “B”  has  experienced  a  funding  cut 

•  PMO  “B”  is  slightly  behind  schedule 

•  There  are  some  requirements  for  system  “B”  that  are  non-critical  for 
PMO  B  (and  its  associated  users) 

•  One  obvious  approach  for  PMO  “B”  would  be  to  delete  some  non- 
critical  requirements  (to  reduce  total  development  costs,  and  possibly 
gain  some  schedule  relief) 

However ...  Those  “non-critical”  requirements  are  essential  for  PMO 

“C”  and  SoSBC 

•  Deferring  or  deleting  these  requirements  would  cause  PMO  “C”  and/or 
SoSBC  to  fail  to  satisfy  their  schedule  and  performance  goals 

So...  Whaddyado  if  you’re  PMO  “B”? 
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One  Possible  Approach 


IMs  in  SoS  Programmatics 
SSTC  2009 

Jim  Smith:  April  21,  2009 

©2009  Carnegie  Mellon  University 


Software  Engineering  Institute  CarnegieMellon 


6 


A  Better  Approach 


Instead  of  “Program  Manager  Whack  A  Mole,”  base  decisions  on 

•  Knowledge  of  the  relevant  interrelationships  between  constituents 
within  a  system-of-systems  context 

•  An  understanding  of  the  origins  and  nature  of  the  underlying  legal  and 
moral  imperatives  that  act  as  constraints  on  a  program  manager 

•  Use  of  a  formal  reasoning  framework  that  allows  one  to  weigh 
competing  constraints  to  arrive  at  a  satisficing  solution — if  one  is 
possible 
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Interrelationships  ■, 


To  understand  the  origins  of  the  conflicts  between  the  individual 
program  (PMO  “B”)  and  the  SoS  (“SOSBC”),  as  well  as  reason  a  way 
through  to  a  satisficing  solution,  additional  information  is  needed 

PMO  “B”  sees  the  following: 
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Interrelationships  2 


At  the  level  of  the  giver-receiver  agreement  between  PMOs  “B”  and  “C,” 
we  have 


giver-receiver 


receiver 


giver 


PMO  “B”  obligations  to  PMO  “C” 

•  Provide  agreed-on  capabilities  in  system  “B”  on  agreed-upon  schedule 

—  Satisfying  quality  attributes,  with  adequate  confidence,  etc. 

•  Not  act  in  a  way  to  violate  agreement 
PMO  “C”  obligations  to  PMO  “B” 

•  Accept  system  “B”  if  it  meets  agreed-upon  schedule  and  capabilities 

•  Not  act  in  a  way  to  violate  agreement  (e.g.,  desired  schedule,  capabilities) 


Interrelationships  3 


There  are  similar  pictures  for  PMO  “C”  and  PEO  “A” 

However,  there  can  be  some  important  differences  between  these 
views 

•  MDAb  might  be  different  than  MDAC 

Different  priorities,  different  perceptions  of  problems  and  solutions 

•  Different  users,  testers,  funding,  etc.  for  PMO  “C” 

There  is  no  “owner”  for  the  acknowledged  SoS  (“SoSBC”) 

•  Maybe  some  explicit  funding,  testing,  etc.  for  SoSBC  ...  but  probably  not 

•  No  explicit  authority  to  make  cross-program  tradeoffs 
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Philosophy,  Modal  Logics,  Legal  Theory,  etc.  ■, 


Problems  of  programmatics  in  systems  of  systems  (or  in  individual 
systems)  do  not  lend  themselves  to  solutions  based  on  propositional 
logic  and  predicate  calculus,  or  conventional  quantitative  methods 
(e.g.,  linear  programming,  multi-criteria  decision-making)  because  of: 

•  Conflicting  normative  obligations  (i.e.,  do  A  fl  — ,A,  B  fl  — ,B,  etc.) 

•  Socio-economic  influences 

•  Other  legal  and  moral  imperatives 

Modal  logics  provide  a  way  to  reason  about  issues  that  are  not  simply 
“black  and  white”: 

•  Belief  (doxastic  logic)  •  Necessity  (alethic  logic) 

•  Time  (temporal  logic)  •  Obligation  (deontic  logic) 

•  Knowledge  (epistemic  logic) 
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Philosophy,  Modal  Logics,  Legal  Theory,  etc.  2 


Modal  logics  widely  used  in: 

•  Modern  philosophy/metaphysics 

Kripke  semantics  and  “possible  worlds”  models 
Speech  acts 

•  Legal  theory 

Side  effects/unintended  consequences  of  legislation 
Reasoning  about  precedent 

•  System  science/computer  science 

Describe  normative  behaviors  of  systems 

And ...  proposed  for  use  in  system -of -systems  programmatics 

“All  of  the  above” 


—  IMs  in  SoS  Programmatics 
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“Laws  of  Programmatics” 


i 


One  possible  set  of  normative  obligations  for  a  program  manager 
includes: 

•  Maximize  satisfaction  of  cost,  schedule,  and  performance  requirements 

•  Obey  all  applicable  laws,  regulations,  directives,  etc. 

•  Take  appropriate  mitigation  steps  when  problems  occur 

•  Be  creative  -  don’t  rely  on  “textbook”  solutions 


Taking  the  first  imperative  (maximize  satisfaction  of  cost,  schedule, 
and  performance  requirements),  we  can  express  this  as: 

O :  the  set  of  all  possible  assertions,  where  cpi  e  ® 

A  :  the  set  of  all  possible  actions,  where  a  e  A 
%  b  max  cost ,  schedule ,  performance 


Or 


a  %  & 


CC  ^  \(P, Q 
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“Laws  of  Programmatics” 


2 


From  the  initial  minimal  set  of  normative  obligations,  we  can  define  a  set  of 
“laws,”  or  meta-behaviors,  for  any  program  manager: 

Zeroth  law:  An  actor  or  constituent  (hereinafter  referred-to  as  actor)  shall  act 
in  such  a  way  so  as  to  maximize  satisfaction  of  applicable  cost,  schedule,  and 
performance  goals  for  the  system. 

First  law:  An  actor  shall  comply  with  all  applicable  laws,  regulations, 
directives,  policies,  etc.  issued  by  “competent  authority”  except  when  doing  so 
would  conflict  with  the  zeroth  or  first  laws. 

Second  law:  An  actor  shall  take  corrective  actions  to  remedy  any  risks, 
issues,  problems  etc.  in  their  program  except  when  such  actions  conflict  with 
the  zeroth,  first,  or  second  laws. 

Third  law:  An  actor  may  “be  creative”  as  long  as  their  actions  do  not  conflict 
with  any  higher  law. 

As  was  previously  shown  for  the  zeroth  law,  these  can  be  expressed  in 
deontic  form 
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“Laws  of  Programmatics” 


3 


By  themselves,  the  laws  are  insufficient 
background  information  is  necessary  to 
analysis.  For  example: 


<pADA  obey  _  anti  -  deficiency  _  act 


O 


ADA 


a  Vada  &  -1  OC  -»  -1  (pADA 


1(0 ADA/ appropriated  _  funds ) 


(pMA  h  obey  _  misappropriation  _ 


O 


MA 


a  Vma  &  -1  oc  ->  -1  (pMA 


1(0 MA! appropriated  _  funds ) 


.  Other  general  knowledge  and 
perform  any  meaningful 


The  truth  of  the  assertion  of  the 
Anti-Deficiency  Act  requires  that  a 
program  obey  the  ADA 


The  ADA  levies  an  obligation  on  a 
program  to  act  so  as  to  preserve 
the  assertion,  and  not — by  failing  to 
act — to  allow  the  assertion  to  be 
falsified 


The  precondition — that  a  program 
uses  appropriated  funds — entails 
the  consequent  that  the  program 
must  comply  with  the  obligation  to 
preserve  the  assertion 
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“Laws  of  Programmatics” 


4 


Let’s  use  these  to  examine  a  typical  problem  from  a  system-centric 
perspective: 

•  Factors  from  the  laws  and  general,  background  knowledge  include: 

f5  :  take  _  appropriate  _  mitigation 

f6  :  be  _  creative 

/7  :  obey  _  applicable  _  laws 

/8  :  has  _  non  -  critical  _  requirements 

f9  :  has  _  schedule  _  slack 

/10  :  delete _  requirements _to _  reduce _ costs 

fx ,  :  delay  _ schedule _to _  reduce _ costs 

fn  :  funds  _  cut 

fl3  :  must  _  reduce  _  costs 
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“Laws  of  Programmatics” 


5 


•  Derived  constituent  conditional  imperatives  include: 

c4  =  ^  fn  ,  /13 ) :  must  reduce  costs  if  funds  cut 

c5  =  (  f13 ,f8  ,floy.  if  required  to  reduce  costs,  and 

has  non  -  critical  requirements,  then  delete  non  - 
critical  requirements 

c6  =  (  f13 ,  f9  ,  fjj  \ :  if  required  to  reduce  costs,  and  has 

schedule  slack,  then  delay  schedule 

c7  =  ^  f  J5):  programs  must  take  appropriate 

mitigation  steps 

c8  =  (  f  ,  f6  ^ :  programs  must  he  creative 

c9  =  (  f  ,  /7 ) :  programs  must  obey  all  applicable  laws 
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Reasoning  Framework 


Conditional  imperatives  define  actions  that  must  be  taken  (consequent)  if 
the  necessary  precondition  (antecedent)  is  true: 

!(O0/  progam_manager ) 

which  is  read  “if  you  are  a  program  manager,  then  you  must  fulfill 
obligation  O” 

Precedents  are  a  subset  of  conditional  imperatives  that  are  applicable  to 
the  instant  case.  A  conditional  imperative  is  applicable  if  it  has  one  or 
more  antecedent  factors  in  common  with  the  instant  case. 

Ant(i )  =  program,  program_manager 

Precedents  can  be  more-or-less  “on  point,”  and  can  be  partially-ordered 
for  a  particular  system-of-systems  context 

•  Precedents  that  are  more  specific,  and  have  more  factors  in  common  with 
the  instant  case  are,  in  general,  more  on  point  than  more  general 
precedents 
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Reasoning  Framework  2 


Precedents  can  trump  other  precedents  (even  if  they  are  more  general) 

•  Obligation  to  obey  31  U.S.C.  §  1517  (Anti-Deficiency  Act)  trumps 
obligation  to  maximize  cost,  schedule,  and  performance  goals 

O0<v  obey_ada 

To  recap: 

•  The  “laws”  (expressed  as  a  series  of  imperatives)  can  be  represented 
(using  deontic  logic)  as  statements  of  obligation 

•  Conditional  imperatives  give  rise  to  precedents 

•  Precedents  can  be  ordered  or  trumped 
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Reasoning  Framework  3 


Application  of  the  laws  requires  a  reasoning  framework 

•  Provides  rules  to  reason  about  a  particular  situation  in  context  through 
successive  refinement,  or  elaboration  to  either  include,  or  exclude, 
particular  factors 

•  Permits  determination  that  there  is  no  constructible  reasoning  chain 
(i.e.,  no  solution  possible) 

Reasoning  chain  begins  with  the  deconstruction  of  conditional 
imperatives  into  factors  (i.e.,  their  consequents  and  antecedents) 

fj  :  is_a _program 
f2  :  uses -appropriated  Junds 
f3  :  must _satisfy_csp -Objectives 
f4  :  must_obey_ada 
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Reasoning  Framework  4 


These  factors  are  combined  to  form  constituents  of  the  set  of 
conditional  imperatives 

cl  =  (  /,  ,f2):  a  progam  is  funded  by  appropriated  funds 

c2  =  (  f  ,  f3  ^ :  a  program  must  satisfy  cost,  schedule, 
and  performance  objectives 

c3  =  (  f2  ,  /4 )  :  appropriated  funds  are  subject  to  the  ADA 


The  relative  rankings  of  the  conditional  imperatives  are  defined 


C1  <X  C2  <X  C3 
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Reasoning  Framework  5 


To  illustrate,  take  a  (really,  really)  simple  example 
Suppose  we  have  the  current  situation  as  described  by: 

X0  =  fj  :  this  is  a  program 

and  we  want  to  ascertain  if  we  are  subject  to  the  Anti  Deficiency  Act  (i.e., 
can  we  use  precedent  to  construct  a  reasoning  chain  to  include  factor/,  in 
a  refinement  of  X0 ?) 

Starting  with  the  initial  situation,  X0,  we  have  f,  — 7 — >  /, ,  /,  which 
shows  that  conditional  imperative  c,  (a  program  is  funded  by 
appropriated  funds)  supports  the  inclusion  of  factor/2  (uses 
appropriated  funds)  as  an  elaboration  of  the  initial  situation. 

Similarly,  conditional  imperative  c3  supports  the  inclusion  of  factor/,, 
represented  as  f,,f2  — - — >•  f,,f2,f4  ,  establishing  that  the  program 
is  subject  to  the  Anti  Deficiency  Act 
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Application  of  the  Reasoning  Framework 


Initial  problem  statement  (from  original  problem  scenario): 

Program  “X”  is  currently  slightly  behind  schedule  and  under  budget,  but 
has  just  sustained  a  funding  cut.  Can  the  program  delete  non-critical  (in 
DoD-ese,  objective)  requirements  to  reduce  costs?  Can  it  delay  schedule 
to  achieve  the  same  results? 

fiJ8^f9Ji2 

Can  we  construct  a  reasoning  chain  to  include  f10  or  fn? 


Reasoning  chain: 

fn  fa’ ft 


■»  fl'fl’fs’fl. 


f  1'  f 2'  f 4’  f 8’  f  1 


1  ’  J  8  ’  J  12  q  r  J  1’  J  2’  J  8’  J  12  ^  J  1>  J  2>  J  4>  J  8>  J  12  c4 

f  1  ’  f  2  ’  f  4  *  f  8  ’  f  12  ’  f  13  f  1  *  f  2  ’  f  4  ’  f  8  ’  f  10  ’  f  12  *  f  13 


Conclusion:  Yes,  objective  requirements  can  be  deleted  to  reduce 
costs,  but  you  cannot  delay  schedule 
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Application  of  the  Reasoning  Framework  2 


What  happens  in  a  systems  of  systems  (e.g.,  SoSBC)? 

Two  additional  “laws”  come  into  force: 

Fourth  law:  An  actor  shall  not  take  unilateral  action  within  their  program  to 
the  detriment  of  another  program,  or  through  inaction,  knowingly  allow 
detriment  to  come  to  another  program  except  when  doing  so  would 
conflict  with  the  fifth  law. 

Fifth  law:  An  actor  shall  not  take  unilateral  action  within  their  program  to 
the  detriment  a  system  of  systems,  or  through  inaction,  knowingly  allow 
detriment  to  come  to  a  system  of  systems. 

We  need  to  elaborate  the  initial  situation  to  include  factors  germane  to 
the  system  of  systems: 

f14  :  in_a_sos 

f15  :  has -requirement -Critical Jor_sos 
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Application  of  the  Reasoning  Framework  3 


The  fourth  and  fifth  laws  give  rise  to  two  additional  conditional 
imperative  constituents 

cw h  (  f,4>  f  15  ’  ^10 )  •'  tf in  an  SoS>  may not 
"injure"  the  SoS  by  deleting  requirements  that 
are  critical  to  the  SoS 

Cn  I-  (  fI4,  fI6  ,->/„) :  if  in  an  SoS,  may  not 
"injure"  the  SoS  by  delaying  schedule 

The  revised  initial  situation  is  now  described  by: 

%0=  fl’fs<  ~f9  ’  fl2  >  fl4  >  flS 

Can  we  construct  a  reasoning  chain  to  include  f10  or  fn? 
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Application  of  the  Reasoning  Framework  4 


Revised  reasoning  chain: 


No  constructible  reasoning  chain  exists: 


» 


C5  ~ flO 

c\o  l/io 


C5  <x  C10 

Bottom  line:  The  inclusion  of  program  “X”  in  a  system  of  systems  context 
results  in  an  inability  to  take  local  action  to  accommodate  the  funding  cut 
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Conclusions 


The  programmatics  of  systems  acquisition  are  complex  ...  systems  of 
systems  even  more  so 

To  get  beyond  current  “program  management  dart  board,”  or  other 
heuristics-based  approaches  to  decision-making  in  this  complex 
environment  requires: 

1 .  A  method  for  identifying  conflicts  between  system-centric  and  system-of- 
systems  contexts 

2.  Some  formal  methods  to  enable  program  managers  to  recognize 
potential  solutions  to  seemingly  intractable  problems 

Modal  logics — and  an  accompanying  reasoning  framework — appear 
well-suited  to  this  task 


IMs  in  SoS  Programmatics 
SSTC  2009 

Jim  Smith:  April  21,  2009 

©2009  Carnegie  Mellon  University 


Software  Engineering  Institute  CarnegieMellon 


27 


Future  Work 


This  work  is  still  fairly  immature  ...  several  avenues  are  being  explored, 
including: 

•  Incorporation  of  additional  modalities  (i.e.,  epistemic  and  doxastic)  and 
temporal  logic  to  deal  with  the  “knowingly”  aspects  of  the  fourth  and  fifth 
laws,  as  well  as  changes  over  time 

•  Elaboration  of  “injure”  in  the  context  of  a  “theory  of  agreements” 

•  Incorporation  of  Ashley’s  factor  weighting  and  magnitude 
considerations  to  refine  determination  of  precedent  applicability 

Currently  applying  this  approach  to  a  case  study 

•  Synthesized  from  several  customer  engagements 

•  Underlying  phenomena  well  understood;  provides  a  good  surrogate  for 
“ground  truth” 
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